Skip to content

fix(drive): warn when anchor field targets Workspace editor files#487

Open
seang1121 wants to merge 2 commits intogoogleworkspace:mainfrom
seang1121:fix/169-warn-anchored-comments
Open

fix(drive): warn when anchor field targets Workspace editor files#487
seang1121 wants to merge 2 commits intogoogleworkspace:mainfrom
seang1121:fix/169-warn-anchored-comments

Conversation

@seang1121
Copy link
Contributor

Summary

Fixes #169

  • When gws drive comments create includes an anchor field, the Drive helper now fetches the target file's mimeType via files.get before the command executes
  • If the file is a Google Workspace editor file (Docs, Sheets, Slides, Drawings), a yellow warning is printed to stderr explaining that anchors are silently ignored by the editor UI
  • If the mimeType cannot be determined (e.g., no auth configured), a general warning is printed instead
  • The command still executes normally — this is a non-blocking warning only
  • Warning follows existing eprintln! + error::yellow() patterns (same as accessNotConfigured guidance)

Workspace editor MIME types checked:

  • application/vnd.google-apps.document (Google Docs)
  • application/vnd.google-apps.spreadsheet (Google Sheets)
  • application/vnd.google-apps.presentation (Google Slides)
  • application/vnd.google-apps.drawing (Google Drawings)

Example warning output:

⚠️  Warning: anchor field ignored for Google Docs files.
   Google Workspace editors treat anchored comments as un-anchored.
   The comment will be created but may show as "Original content deleted".
   See: https://developers.google.com/workspace/drive/api/v3/manage-comments

Test plan

  • Unit tests for is_workspace_editor_mime() — all 4 editor types + 3 non-editor types
  • Unit tests for mime_display_name() — all 4 named types + fallback
  • cargo test passes locally for new tests
  • Manual: gws drive comments create with anchor on a Google Doc shows warning
  • Manual: gws drive comments create with anchor on a PDF does not warn
  • Manual: gws drive comments create without anchor does not warn

…ogleworkspace#169)

When `gws drive comments create` includes an `anchor` field, the helper
now checks the target file's mimeType via `files.get`. If the file is a
Google Workspace editor file (Docs, Sheets, Slides, Drawings), a warning
is printed to stderr explaining that the anchor will be silently ignored
by the editor UI and the comment may show as "Original content deleted".

If the mimeType cannot be determined (e.g., unauthenticated), a general
warning is printed instead. The command still executes — this is a
non-blocking warning only.

Fixes googleworkspace#169
@changeset-bot
Copy link

changeset-bot bot commented Mar 14, 2026

🦋 Changeset detected

Latest commit: e04e138

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package
Name Type
@googleworkspace/cli Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

@googleworkspace-bot googleworkspace-bot added the area: core Core CLI parsing, commands, error handling, utilities label Mar 14, 2026
@gemini-code-assist
Copy link
Contributor

Summary of Changes

Hello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request enhances the gws drive comments create command by introducing a proactive warning system. It addresses a known issue where anchored comments on Google Workspace editor files are not respected by the editor UI. By fetching the file's MIME type and alerting the user if it's an editor file, the change improves user awareness and prevents potential confusion regarding comment placement, without disrupting the command's core functionality.

Highlights

  • Anchored Comment Warning: The gws drive comments create command now warns users if an anchor field is used when targeting Google Workspace editor files (Docs, Sheets, Slides, Drawings), as anchors are silently ignored by the editor UI.
  • MIME Type Detection: The Drive helper fetches the target file's mimeType via files.get before command execution to determine if a warning is necessary.
  • Warning Mechanism: A yellow warning is printed to stderr, explaining the behavior. If the mimeType cannot be determined (e.g., due to auth issues), a general warning is displayed. The command still executes normally, as the warning is non-blocking.
  • Code Structure: New functions warn_anchored_comment_if_needed, fetch_file_mime_type, is_workspace_editor_mime, and mime_display_name were introduced to support this functionality, along with a constant list of Workspace editor MIME types.
Changelog
  • .changeset/warn-anchored-comments.md
    • Added a new changeset entry documenting the warning for anchored comments on Google Workspace editor files.
  • src/helpers/drive.rs
    • Added WORKSPACE_EDITOR_MIMES constant for Google Workspace editor file types.
    • Integrated warn_anchored_comment_if_needed into the execute_command method.
    • Implemented warn_anchored_comment_if_needed to check for anchored comments on Workspace editor files and display appropriate warnings.
    • Implemented fetch_file_mime_type to retrieve the MIME type of a Drive file.
    • Implemented is_workspace_editor_mime to identify Google Workspace editor MIME types.
    • Implemented mime_display_name to provide user-friendly names for specific MIME types.
    • Added unit tests for is_workspace_editor_mime and mime_display_name.
Activity
  • Unit tests for is_workspace_editor_mime() were completed, covering all 4 editor types and 3 non-editor types.
  • Unit tests for mime_display_name() were completed, covering all 4 named types and the fallback.
  • cargo test passes locally for the newly added tests.
  • Manual testing is pending for gws drive comments create with an anchor on a Google Doc to confirm the warning appears.
  • Manual testing is pending for gws drive comments create with an anchor on a PDF to confirm no warning appears.
  • Manual testing is pending for gws drive comments create without an anchor to confirm no warning appears.
Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help /gemini help Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

  1. Review the Generative AI Prohibited Use Policy, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

Copy link
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request introduces a new warning mechanism for the drive comments create command. It detects when a user attempts to create an anchored comment on Google Workspace editor files (Docs, Sheets, Slides, Drawings), where the anchor field is silently ignored by the editor UI. The changes include adding a constant for Workspace editor MIME types, integrating an asynchronous warning function into the command handler, and implementing helper functions to fetch file MIME types, check for Workspace editor MIME types, and provide display names for them. Unit tests for the new helper functions are also included.

The upstream bot token secret doesn't exist in this fork, causing all
workflows to fail at checkout with "Input required and not supplied: token".
@googleworkspace-bot
Copy link
Collaborator

/gemini review

Copy link
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request introduces a helpful warning for users creating anchored comments on Google Workspace files, where anchors are not supported. The implementation is well-structured, making a separate API call to check the file's MIME type and providing clear, contextual warnings. The addition of unit tests for the new helper functions is also a great practice. I've found one potential issue with how a JSON payload is constructed, which could be vulnerable to malformed input.

let scopes: Vec<&str> = get_method.scopes.iter().map(|s| s.as_str()).collect();
let token = auth::get_token(&scopes).await?;

let params = format!(r#"{{"fileId":"{}","fields":"mimeType"}}"#, file_id);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

high

Constructing JSON via string formatting is vulnerable to injection if file_id contains special characters like quotes. This can lead to a panic or API errors. It's safer to use serde_json::json! which handles escaping correctly.

Suggested change
let params = format!(r#"{{"fileId":"{}","fields":"mimeType"}}"#, file_id);
let params = serde_json::json!({ "fileId": file_id, "fields": "mimeType" }).to_string();

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area: core Core CLI parsing, commands, error handling, utilities area: distribution

Projects

None yet

Development

Successfully merging this pull request may close these issues.

drive comments create: anchor field results in 'Original content deleted' in Google Docs

2 participants